A question that often comes up when dealing with a new SharePoint deployment is, “Who should control the assignment of user permissions to a SharePoint site?” Many times the instinctive response to this question is, the Network Administrator's, of course. As standard as this might seem in most organizations, when it comes to SharePoint this is actually not the avenue that we want to take. SharePoint is, by its very nature, a User based product, and as such should be under the control of the users who must use and maintain the data within.
The SharePoint boundary for permission inheritance really begins with the Site Collection. Each Site Collection maintains its own list of roles and users assigned to those roles as well as the level of access each role has within that Site Collection. Inside of the collection this inheritance can be broken at any level, sub-site, list, library or even item. While this is not really a best practice, due to the limitations within SharePoint for managing permissions, it is often a necessity to control who has access to specific information within the collection. The issue is that SharePoint itself has no mechanism for reporting what permissions a user or group has within its boundaries. While you could check each site, list or item to see what permissions someone has to that item, you can't see the permissions that are assigned someone throughout the Site or Collection. Also, SharePoint has no means of copying one users permissions to another should you need to do this. There are 3rd party solutions that can assist you in handling some of these limitations however, such as DeliverPoint from Barracuda Tools or Quests Administration Tools for SharePoint.
What this means is that a role must be created for each level of access that a different set of users will require, for each site, list, or library where you break inheritance. If your Active Directory administrators are expected to maintain the memberships of these groups, that also means that anytime a Site Collection or Site owner needs to grant or modify a users access to information within the site, this will require a ticket to be placed with IT to make the change. This can have a very detrimental effect to fluid collaboration, the cornerstone of what SharePoint is supposed to bring to your organization.
As a user focused product, the management of access rights to SharePoint content really must fall to the owner of that content, be it the Site Collection Administrator, Site Owner, etc. The user who owns, or is responsible for, the information within a Site should also then be responsible for assigning who has what access to that information. This stipulation should also then drive the taxonomy of your SharePoint deployment. If the content requires a different set of permissions, it should be in a different site. That said, training is an important aspect of any SharePoint deployment as Site Collection Administrators and Site Owners should be trained on the proper methods for granting users access to the information contained within their sites.
Chapter 6 of the SharePoint Best Practices book (Microsoft Press, Ben Curry and Bill English) has a good description of some of the issues that can arise when trying to control SharePoint access from a central team. This section also includes a list of the pros and cons around using SharePoint groups vs. Active Directory groups for assigning access permissions in SharePoint. (Another long standing debate in SharePoint deployments.) There are good reasons to use both of these methods to grant users access to SharePoint resources, but in each case, that association should be done by the people responsible for the content, and not the individuals responsible for the rest of your network. SharePoint is designed to be used, managed, and populated by the community that uses it, your users. Train them and let them collaborate.